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(57) Abstract 



The invention relates to a method for checking Java byte code programmes for security characteristics. The technical aim of the 
invention is to provide a method for guaranteeing the best possible security in checking the security characteristics of byte code programmes. 
According to the invention, the mode of operation of the byte code programme being checked is configured for a finite status transition 
system (M) and the state space of the JVM is configured for a finite quantity of states in M. After being entered into a model checker, 
the data of the status transition system (M) is compared with the data in the model checker, the data in the model checker having been 
entered as a set of conditions (S) for the characteristics of a reliable byte code programme. The byte code programme being checked is only 
released for further processing if the status transition system (M) fulfils all of the conditions of the set (S). The invention therefore provides 
a means of guaranteeing the security of byte code programmes and with additional enhancements, can guarantee a certain functionality. 
This increases the reliability of applications which are run on security-critical platforms such as smart cards. 

(57) Zusammenfassung 

Die technische Aufgabe ist auf ein Verfahren ausgerichtet, das eine hochstmagliche Sicherheit bei der Oberprttfung von 
Sicherheitseigenschaften von Bytecode-Programmen gewahrleistet ErfindungsgemaB wind die Funktionsweise des zu prflfenden 
Bytecode-Programms auf ein endliches ZustandsQbergangssystem (M) und der Zustandsraum der JVM auf eine endliche Menge von 
Zustanden in M ausgebildet Nach Eingabe in einen Modelchecker werden die Daten des endlichen Zustandsubergangssystem (M) mit den 
im Modelchecker als Bedingungsmenge (S) eingegebenen Daten fur Eigenschaften die ein zulassiges Bytecode-Programm kennzeichnen, 
verglichen. Das zu flberprOfende Bytecode-Programm wird nur zur weiteren Verarbeitung freigegeben, wenn das Zustandsflbergangssystem 
(M) alle Bedingungen der Bedingungsmenge (S) erfullL Durch die beschriebene Technik kann die Sicherheit von Bytecode-Programmen 
garantiert und durch zusStzliche Erweiterungen eine gewisse Funktionalitat zugesichert werden. Damit kann das Vertrauen in Anwendungen 
erhoht werden, die auf sicherheitskritischen Plattformen wie Smartcards ablaufen sollen. 
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Verfahren zur Prufung von Java-Bytecodc-Programmen auf Sicherheitseigenschaften 
Beschreibung: 

Die Erfindung betrifft ein Verfahren zur Prufung von Java-Bytecode-Programmen auf 
Sicherheitseigenschaften nach dem Patentanspruch 1. 

Java 1st eine von Sun Microsystems entwickelte Programmiersprache, die in sog. Bytecode- 
Programme ubersetzt wird. Obwohl urspriingUch fur Java entworfen, eignet sich Bytecode 
auch als Zielsprache fur andere Programmiersprachen, und es gibt bereits entsprechende 
Compiler (z. B. for Ada). 

Das besondere Konzept von Java besteht darin, Programme im Netz abzulegen und von 
Netzteilnehmern abrufen zu lassen, urn sie auf einem Gerat des Netzteilnehmers ablaufen zu 
lassen. Dies unterstutzt z. B. die Konfiguration und Warning von Geraten aus der Feme, ist 
aber auch im Zusammenhang mit Smartcards interessant, deren Funktionalitat sich auf diese 
Weise erweitem laBt. Bytecode-Programme haben folgende Eigenschaften, die for ihren 
Einsatzzweck bedeutend sind: 

• Bytecode-Programme sind kompakt. Bytecode-Instruktionen bieten wesentlich mehr 
Funktionalitat als z. B. Instruktionen von Maschinensprachen. Durch die Anlehnung an 
Java werden Konzepte wie Objektorientierung direkt unterstutzt. 

• Bytecode-Programme konnen effizient interpretiert werden. Dies verleiht solchen 
Programmen Unabhangigkeit von einer bestimmten Zielmascbine. Vorausgesetzt wird 
lediglich ein Interpreter (die sog. "Java virtual machine", JVM) auf der Zielmaschine, 
urn beliebige Bytecode-Programme ausfohren zu konnen. Dieser Interpreter kann selbst 
kompakt implementiert und in (fast) jedes Gerat integriert werden. 

Die JVM interpretiert eine Eingabe in Form einer Folge von Zeichen als Bytecode- 
Programm. Die JVM nimmt dabei keine Priifungen vor, ob es sich bei der Zeichenfolge 
tatsachlich um ein Bytecode-Programm handelt. Sie verarbeitet die Zeichen als Bytecode- 
Befehle, ohne eine genauere Prufung auf ihre Korrektheit durchzufohren. Die JVM 
verzichtet auf eine Uberprufung des Bytecodes, da sonst die Ausfohrungsgeschwindigkeit 
erhebhch leiden wurde. Prinzipiell ist es also moglich, eine beliebige Folge von Zeichen als 
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Bytecode-Programm interpretieren zu lassen. Dadurch ware es auch moglich - bei 
genauerer Kenntniss der Implementierung der JVM - ihre Sicherheitsmechanismen zu 
umgehen und damit z. B. auf dem ausfuhrenden Rechner Daten auszuspahen. Ein sicheres 
Bytecode-Programm kann dagegen aufgrund des Sprachentwurfs und der JVM auf Daten 
und Ressourcen des Zielrechners nur zugreifen, indem es dafiir Funktionen der JVM in 
Anspruch nimmt. 

Urn zu verhindern, daB Zeichenfolgen verarbeitet werden, die keine zulassigen (sicheren) 
Bytecode-Programme darstellen, ist der JVM ein ProzeB vorgeschaltet, der eine 
Zeichenfolge auf Konformitat zu gewissen Anforderungen uberpriift, die sog. Bytecode- 
Verifikation. Diese Anforderungen garantieren, daB eine Zeichenfolge ein sicheres 
Bytecode-Programm darstellt. Da diese Oberpriifung nur einmal vorgenommen werden 
muB, entstehen zur Laufzeit keine Nachteile bzgl. der Ausfuhrungsgeschwindigkeit. 
Der ProzeB der Bytecode-Verifikation priift eine Folge von Zeichen daraufhin, ob sie ein 
zulassiges Bytecode-Programm darstellt und damit ohne Gefahr fur die Integritat des 
ausfuhrenden Gerats der JVM zur Interpretierung ubergeben werden kann (siehe T. 
Lindholm, F. Yellin „The Java Virtual Machine Specification"; Sun Microsystems; Addison- 
Wesley, 1996. 

Ein zulassiges Bytecode-Programm ist durch gewisse Eigenschaften gekennzeichnet, die in 
T. Lindholm, F. Yellin: The Java Virtual Machine Specification. Sun Microsystems, 1996 
als "structural constraints" beschrieben werden. Im wesentlichen beschreiben sie die 
Typsicherheit eines Bytecode-Programms, d. h. in einem Bytecode-Programm sind die 
Instruktionen so angeordnet, dafl eine Instruktion stets solche Daten als Parameter 
bekommt, die ihrem Typ nach dem entsprechen, was die Instruktion erwartet. Diese 
Eigenschaften steUen sicher, daB das Bytecode-Programm unter KontroUe der JVM bleibt 
und z. B. nicht direkt auf Rechnerressourcen zugreifen kann. 

Der ProzeB der Bytecode-Verifikation ist durch zwei Gegebenheiten beschrieben: erstens 
durch die Beschreibung der Eigenschaften, die er for ein Bytecode-Programm zusichern 
soil; zweitens durch die Implementierung des Prozesses (dabei handelt es sich urn ein C- 
Programm). Beide Beschreibungen eignen sich nicht, urn formale, maschineUe 
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Berechnungen durchzufuhren und damit die Sicherheit von Bytecode-Programmen formal 
zu garantieren. 

Weiterhin ist ein mit Modelchecker bezeichnetes Werkzeug zur Untersuchung von 
Zustandsubergangssystemen bekannt (siehe K. L. Mc Millan „Symbolic Model Cheking" 

5 Kluwer Academic Publishers, 1993). 

Zustandsiibergangssysteme sind ein allgemeines Modell fur Programme, die auf Rechnern 
oder anderen Maschinen (wie der JVM) ablaufen. Dabei betrachtet man die Zustande, die 
die Maschine wahrend der Ausfuhrung des Programmes einnimmt und welche Ubergange, 
d. h. Zustandsanderungen, dabei moglich sind. 

10 Modelchecking ist eine Technik, mit der nur endliche Zustandsiibergangssysteme untersucht 
werden konnen. Ein Modelchecker untersucht dafiir den gesamten Zustandsraum des 
Systems, urn Eigenschaften des Systems zu berechnen. Eine verbreitete Anwendung von 
Modelcheckern ist, ein System daraufhin zu priifen, ob es gewisse Eigenschaften erfullt. Der 
Modelchecker benotigt dafiir als Eingabe eine Beschreibung des Systems, das untersucht 

15 werden soil sowie die Beschreibung von Eigenschaften, deren Giiltigkeit im System 

festgestellt werden soil. In beiden Fallen handelt es sich um formale Beschreibungen, d. h. 
Beschreibungen, deren formale Semantik feststeht, und auf denen somit mathematische 
Berechnungen durchgefiihrt werden konnen. 

20 Im allgemeinen besitzen Software-Systeme auch Bytecode-Programme einen unendlichen 
Zustandsraum. Das bedeutet, daB das Verfahren des Modelchecking auf Bytecode- 
programme, die durch einen unendlichen Zustandsraum gekennzeichnet sind, nicht 
anwendbar ist. 

25 Die technische Aufgabe ist auf ein Verfahren ausgerichtet, das eine hochstmogliche 

Sicherheit bei der Uberpriifung von Sicherheitseigenschaften von Bytecode-Programmen 
gewahrleistet. 

Ausgangspunkt des erfindungsgemaBen Verfahrens ist der Sachverhalt, daB ein Bytecode- 
30 Programm eine Folge von Zeichen (Bytes) beinhaltet, wobei jedes Zeichen entweder als 
Instruktion oder als Datum (als Eingabe fur die vorhergehende Instruktion) interpretiert 
wird. Ein Bytecode-Programm stellt somit eine Folge von Instruktionen und zugehorigen 
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Daten dar. Ein Bytecode-Programm kann damit auch als Beschreibung eines 
Zustandsubergangssystems gedeutet werden, das Zustande der JVM transformiert. Die 
Zustande des Systems werden mit den Zustanden der JVM identifiziert und die Ubergange 
durch die Instruktionen des Programms festgelegt. 

ErfindungsgemaB wird das oben beschriebene Zustandsubergangssystem (mit potentiell 
unendlichem Zustandsraum) durch eine geeignete Abbildung auf ein System mit einer 
endlichen Anzahl von Zustanden abgebildet. Diese Abstraktion auf eine endliche Anzahl von 
Zustanden wird dadurch erreicht, daB das System alle Informationen verwirft, die nicht 
benotigt werden, urn festzustellen, ob das urspriingliche Bytecode-Programm zulassig ist. 
Dies geschieht im wesentlichen dadurch, daB die konkreten Datenwerte durch reine 
Typinformationen ersetzt werden. Der Ersatz der konkreten Datenwerte durch reine 
Typinformationen ist moglich, weil die Zulassigkeit eines Bytecode-Programms nicht von 
konkreten Werten abhangt. Dabei bleiben aber aUe Informationen, die notwendig sind, urn 
die Zulassigkeit des Bytecode-Programms nachzuweisen, erhalten. Das resultierende 
Zustandsubergangssystem M besitzt eine endliche Menge von Zustanden und erfullt damit 
die Grundbedingung fur die Bearbeitung in einem Modelchecker. Das resultierende 
Zustandsubergangssystem M wird in den Modelchecker eingegeben. 
In einem weiteren Schritt werden die Eigenschaften, die wie in T. Lindholm, F. Yellin: The 
Java Virtual Machine Specification. Sun Microsystems, 1996 als "structural constraints" 
beschrieben, ein zulassiges Bytecode-Programm kennzeichnen, in einer Logik formuliert, 
die der Modelchecker als Spezifikationssprache fur Systemeigenschaften versteht. Das 
Ergebnis ist eine Menge von Formeln, die dem Modelchecker als Bedingungsmenge S als 
Vergleichsbasis fur das Zustandsubergangssystem M ubergeben werden. Aufgrund der o.g. 
Verfahrensweise ist gewahrleistet, daB sich die Formeln nur auf Informationen beziehen, 
die sowohl im ursprunglichen, potentieU zustandsunendlichen System, als auch im daraus 
gewonnenen zustandsendUchen System vorhanden sind. 

Der Modelchecker wird mit den eben beschriebenen Eingaben gestartet. Als Ergebnis liefert 
er die Information, ob das Zustandsubergangssystem M die in der Spezifikationssprache als 
Bedingungsmenge S in Form von Formeln beschriebenen Systemeigenschaften erfullt. 
Dabei pruft der Modelchecker fur jede Bedingung s der Bedingungsmenge S, ob sie - 
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Zustandsubergangssystem M des zu priifenden Bytecode-Programms erfiillt ist. Wenn das 
der Fall ist, so ist sichergestellt, daB es sich bei dem urspriinglichen Bytecode-Programm urn 
ein zulassiges Programm handelt, das die Sicherheit des ausfiihrenden Rechners nicht 
bedroht. Das Bytecode-Programm wird zur weiteren Bearbeitung durch den Rechner 
freigegeben. 

Erfiillen die im Zustandsubergangssystem M erfaCten Daten des zu priifenden Bytecode- 
Programms jedoch nicht die in der Bedingungsmenge S in Form von Formeln beschriebenen 
Systemeigenschaften, die ein Bytecode-Programm kennzeichnen, ist grundsatzlich davon 
auszugehen, daB das gepriifte Bytecode-Programm die Sicherheit des Rechners bedrohen 
kann. Das gepriifte Bytecode-Programm wird nicht zur weiteren Bearbeitung freigegeben.. 

Das erfindungsgemafie Verfahren wird nachfolgend naher erlautert: 

Zweck der "Bytecode-Verifikation" ist es, eine Klassendatei, also die Einheit, in der eine 

Java-Klassenbeschreibung zusammengefaBt ist, auf sichere Ausfiihrbarkeit zu priifen. Dazu 

werden die einzelnen Methoden der Klasse (hier Bytecode-Programme genannt) einzeln 

herausgelost und der eigentlichen Bytecode-Verifikation unterzogen. 

Eine Klassendatei enthalt zusatzliche Daten, im wesentlichen Konstanten, auf die in den 

Bytecode-Programmen Bezug genommen wird. Fur die folgenden Schritte ist es vorteilhaft, 

diese Referenzen in den Bytecode-Programmen aufzulosen und in die Programme 

einzuarbeiten, bevor mit der eigentlichen Priifung begonnen wird. 

Durch diese Vorverarbeitung erhalt man eine Beschreibung der Bytecode-Programme, die 
sich nicht wesentlich von der urspriinglichen Form unterscheidet 

Die JVM, der Standard-Interpreter fur Bytecode-Programme, ist durch eine abstrakte 
Maschine, d.h. eine Menge von Zustanden, beschrieben. Die Ausfiihrung eines Bytecode- 
Programms entspricht der Interpretation von Bytecode-Instniktionen durch 
Zustandsubergange. Eine Bytecode-Instruktion bewirkt dabei eine Transformation des 
aktuellen Zustands der JVM in einen neuen Zustand. 

Ein Bytecode-Programm definiert also ein Zustandsubergangssystem, wobei der 
Zustandsraum durch die JVM festgelegt ist und die Ubergange durch die Instniktionen des 
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Bytecode-Programms bestimmt werden. Dieses Zustandsiibergangssystem besitzt einen 
potentiell unendlichen Zustandsraum. Deshalb ist es nicht geeignet, urn von einem 
Modelchecker untersucht zu werden. Dazu mufi es auf ein endliches 
Zustandsiibergangssystem M abgebildet werden. Diese Abbildung wird im folgenden 
5 beschrieben. 



Es wird nicht zunachst ein unendliches Ubergangssystem konstruiert, das anschlieBend auf 
ein endliches abgebildet wird. Vielmehr wird aus dem Bytecode-Programm direkt ein 
endliches Zustandsiibergangssystem M konstruiert, unter Verwendung von Regeln, die das 

10 Verhalten der Bytecode-Instniktionen beschreiben. 

Die Funktionsweise eines Bytecode-Programms wird abgebildet auf ein endliches 
Zustandsiibergangssystem M. Der Zustandsraum der JVM wird auf eine endliche Menge 
von Zustanden im Zustandsiibergangssystem M abgebildet. Die Bytecode-Instruktionen 
bewirken dann Ubergange auf dieser endlichen Zustandsmenge, wobei ihre prinzipielle 

15 Wirkung erhalten bleibt. Das Zustandsiibergangssystem M wird so beschrieben, daB diese 
Beschreibung als Eingabe fur den Modelchecker dienen kann. 



Die Eingabe fur den Modelchecker besteht aus zwei Teilen: 

1 . Einer als Zustandsiibergangssystem M bezeichneten Systembeschreibung, bestehend aus 
20 - einer Beschreibung des Zustandsraums, festgelegt durch die Zustandsvariablen und 
ihre Wertebereiche; 

- einer Vorschrift, die die Startzustande des Systems festlegt; 

- einer Ubergangsrelation, die angibt, wie Zustande transformiert werden und unter 
welchen Bedingungen. 

25 2. Einer Menge von Spezifikationen, die als Bedingungsmenge S bezeichnet werden und 
die die gewunschte Eigenschaften eines zulassigen Bytecode-Programms beschreiben. 
Diese Eigenschaften werden von dem Zustandsiibergangssystem M verlangt, das durch 
das Bytecode-Programm beschrieben wird. So kann die Sicherheit bei der Ausfuhrung 
des Bytecode-Programms garantiert werden. Diese Eigenschaften gelten im konkreten, 

30 unendlichen Zustandsubergangssystem (und damit im urspriinglichen Bytecode- 
Programm) dann, wenn sie im abstrakten, endlichen Zustandsubergangssystem M 
gelten. Der Modelchecker priift, ob sie im abstrakten Zustandsubergangssystem M 
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gelten. Falls dies der Fall ist, darf man schlieflen, daB die Eigenschaften auch vom 
konkreten System und damit im urspriinglichen Programm erfullt werden. 

Die Erzeugung der erforderlichen Daten wird im folgenden beschrieben: 
5 Der Zustandsraum des Zustandsiibergangssystems M ist aus folgenden Komponenten 
aufgebaut: 

- Einem Befehlszahler. 

Einem Operanden-Stack, der die Parameter und Ergebnisse von Instruktionen aufiiimmt. 

- Einem Feld von lokalen Variablen. 
10 - Einem Feld von globalen Variablen. 

Variablen fur das Mitfuhren von buchhalterischen Informationen; auf diese kann 
zuriickgegriffen werden, urn Eigenschaften des Systems zu beschreiben, die mit den 
iibrigen Komponenten nicht beschrieben werden konnen. Hierzu gehort u.a. ein 
Stack, der Informationen uber die aktiven Subroutinen (Unterprogramme in einem 
15 Bytecode-Programm) enthalt. 

Die Werte von Variablen und Stackelementen stammen aus endlichen Wertebereichen. Der 
Befehlszahler kann eine endliche Zahl von Adresswerten annehmen. Der Operanden-Stack 
ist in der Hohe begrenzt. Insgesamt ist der Zustandsraum von M dadurch endlich. 



20 Das Befehlsverzeichnis V enthalt Beschreibungen aller Bytecode-Instruktionen, bestehend 
aus folgenden Informationen je Instruktion: 

■ Die Bezeichnung der Instruktion (1 Byte). 

■ Die Anzahl der Parameter in Bytes (Zeichen). 

■ Eine Beschreibung der Wirkung auf Zustande der JVM. 

25 ■ Bedingungen, die ein Zustand der JVM erfullen muB, damit die Instruktion angewendet 
werden kann (CI). 

■ Bedingungen (C2), die die JVM erfullen muB, weil die Instruktion im Programm 
vorkommt. Diese Bedingungen beziehen sich nicht notwendigerweise auf einzelne 
Zustande, sondern auch auf Ausfuhnmgspfade, d.h. Folgen von Zustanden. 

30 Fur die Bedingungen in V gilt folgende Eigenschaft (Al): Die Beschreibung der 
Bedingungen im Befehlsverzeichnis V verwendet nur solche Symbole, die bei der 
Beschreibung des Zustandsraums fur M verwendet werden. 
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Ein Ubersetzer erzeugt aus einem Bytecode-Programm ein endliches 
Zustandsiibergangssystem. Das Bytecode-Programm liegt als Folge von Zeichen in der 
Eingabe vor, wobei ein einzelnes Zeichen als Instruktion oder Parameter einer Instruktion 
gedeutet werden kann. Das erste Zeichen wird als Instruktion gedeutet. 

5 

Ziel der Ubersetzung ist die Konstruktion eines Zustandsiibergangssystems M und einer 
Bedingungsmenge S. Der UbersetzungsprozeB ist wie folgt beschrieben: 

1 . Beginne mit einem initialen ("leeren") Ubergangssystem M. Der Zustandsraum von M 
ist schon festgelegt durch die abstrakte Representation des JVM-Zustandsraums. Der 

10 Startzustand der JVM legt aber den Startzustand von M fest. Es sind jedoch noch keine 
Ubergange zwischen den Zustanden festgelegt. 

2. Beginne mit einer leeren Bedingungsmenge S. 

3. Solange Zeichen in der Eingabe vorhanden sind, fiihre folgende Schritte 4 bis 8 durch: 

4. Lies ein Zeichen von der Eingabe; dieses bezeichnet die Programminstruktion B. 
15 5. Schlage im Befehlsverzeichnis V nach, welche Parameter B bendtigt 

6. Lies die fur B benotigten Parameter P von der Eingabe. 

7. Ubergebe (B,P) an die Abstraktionskomponente. 

8. Ubergebe (B,P) an die Bedingungskomponente. 

20 Die Abstraktionskomponente erzeugt aus einer Instruktion B und zugehorigen Parametern 
P eine Menge von Zustandsiibergangen. Das Zustandsiibergangssystem M wird um diese 
Ubergange erweitert. 

1 . Schlage im Befehlsverzeichnis V nach, welche Wirkung B auf einem Zustand der JVM 
hat. Die Wirkung ist durch eine Regel beschrieben, so dafi sich der Folgezustand der 

25 JVM aus einer Berechnung auf dem aktuellen Zustand ergibt. (Eine explizite Angabe 
der moglichen Ubergange ist nicht moglich, da die JVM iiber einen (praktisch) 
unendlichen Zustandsraum verfugt.) 

2. Erzeuge daraus eine Beschreibung der Wirkung auf Zustande von M unter 
Beriicksichtigung von P. Die Parameter P gehen in die Berechnung des Folgezustands 

30 ein. Wendet man eine JVM-Regel auf einen M-Zustand an, so erh&lt man eine Menge 
von M-Zustanden, die die moglichen Folgezustande der JVM reprasentieren. Es ergibt 
sich eine Menge von Folgezustanden fur M, da nicht die konkreten Werte in P, sondern 
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nur die fur M relevanten Informationen betrachtet werden. Welcher JVM-Folgezustand 
bei Ausfiihrung des Bytecode-Programms tatsachlich eingenommen wird, hangt von den 
konkreten Werten in P ab. 
3 . Diese Beschreibung legt eine Menge von Zustandsubergangen fest; erweitere M urn 
diese Ubergange. Diese Ubergange konnen durch eine Regel beschrieben oder explizit 
angegeben werden. Letzteres ist moglich, da M nur eine endliche Zahl an Zustanden 
kennt und deshalb alle Ubergange durch Zustandspaare angegeben werden konnen. 
Letztlich lehnt sich die Beschreibung daran an, was der verwendete Modelchecker 
versteht. Aus praktischen Grunden wird man eine explizite Angabe aller Ubergange 
vermeiden, da die Datenmenge hierfur weit groBer ist als bei der impliziten Angabe 
durch Regeln. 

Die Bedingungskomponente erzeugt aus (B,P) eine Menge von Bedingungen, die vom 
Modelchecker letztlich zu priifen sind. Diese Bedingungen konnen auf verschiedene Art 
reprasentiert werden, etwa durch temporallogische Formeln. 

1 . Schlage im Befehlsverzeichnis V nach, welche Bedingungen C 1 an den aktuellen JVM- 
Zustand gestellt werden, damit B ausgefuhrt werden kann. 

2. tfbertrage CI auf entsprechende M-Bedingungen. Laut (Al) sind die Bedingungen in V 
und die Zustandsbeschreibung fur M so aufeinander abgestimmt, daB CI auf M- 
Zustanden interpretiert werden kann. Die Ubertragung auf M besteht im wesentlichen 
daraus, mittels P konkrete Instanzen von CI zu erzeugen und in eine logische Formel zu 
iibersetzen. 

3. Schlage entsprechend die Bedingungen C2 nach, die fur das gesamte System M durch 
die Verwendung von B entstehen. 

4. Ubertrage entsprechend C2 auf M. 

5. Erweitere die Bedingungsmenge S urn die Darstellungen fur CI und C2. 

Die beschriebene Konstruktion des Zustandsubergangssystems M und der 
Bedingungsmenge S fur ein zu pnifendes Bytecode-Programm lauft vollautomatisch ab. Das 
Befehlsverzeichnis V und seine Bestandteile wird, ebenso wie der Zustandsraum von M, 
einmal festgelegt fur den bestimmten Zweck der "Bytecode-Verij&kation", d.h. der 
Uberpriifung von Sicherheitseigenschaften von Bytecode-Programmen. 
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Nachfolgend wird die Arbeitsweise des Modelcheckers erlautert. 
Der Modelchecker priift fiir jede Bedingung s aus der Bedingungsmenge S, ob sie vom 
Zustandsubergangssystem M erfullt ist. Falls eine Bedingung s nicht erfullt ist, erzeugt der 
Modelchecker Informationen, die zusammen mit der Kenntnis, fiir welche Instruktion s 
erzeugt wurde, verwendet werden kann, urn zu analysieren, wie die Bedingungen an einen 
sicheren Ablauf der JVM durch das Bytecode-Programm verletzt werden konnen. Eine 
typische Ausgabe des Modelcheckers besteht aus der Angabe eines Ausfuhrungspfades, d.h 
einer Folge von M-Zustanden, der in einer Verletzung gewisser Bedingungen mundet. 

Eine genaue Analyse des Ausfuhrungspfades ist nicht notwendig. Ziel der Bytecode- 
Verifikation ist es lediglich festzustellen, ob eine Verletzung der Bedingungen durch das 
Programm moglich ist oder nicht. Informationen uber das Wie konnen interessant sein, sind 
aber nicht notwendig, da lediglich gefordert ist, potentiell unsichere Programme 
abzuweisen. Dabei nimmt man in Kauf, auch sichere Programme abzuweisen, die zwar 
Bedingungen verletzen, deren genauere Analyse aber ergeben wiirde, daB sie in einer 
wirklichen Umgebung keinen Schaden anrichten konnten. Da solche Programme i. allg. 
nicht durch Compiler, sondern nur durch absichtsvolle Codierung entstehen, schrankt man 
sich nicht wesentlich ein. 



Die Steuerung der Bytecode-Verifikation besteht in der Koordinierung der verschiedenen 
Komponentea Eine Klassendatei wird der Bytecode-Verifikation unterzogen, indem 
1 die Bytecode-Programme (Methoden) einzeln herausgelost werden, 

2. die Referenzen im Bytecode-Programm aufgelost werden (Vorverarbeitung), 

3 . ein Zustandssystem und eine Bedingungsmenge konstruiert wird, 

4. der Modelchecker mit dieser Eingabe gestartet wird; 

5 . bei Erfolg des Modelcheckers wird dies fiir das nachste Bytecode-Programm 
wiederholt, bei MiBerfolg wird gemeldet, daB die Bytecode-Verifikation fiir die 
untersuchte Klassendatei fehlgeschlagen ist. 

Das erfindungsgemaBe Verfahren laBt sich noch in einigen Punkten erweitern. 

Von der Art der Abbildung eines Bytecode-Programms auf ein endliches Zustandssystem 

hangt es ab, welche Eigenschaften nachgewiesen werden konnen. Urn etwa die Zulassigkeit 
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eines Bytecode-Programms festzustellen, kann die oben skizzierte Abbildung benutzt 
werden. Durch Wahl einer anderen Abstraktions-Abbildung ist es moglich, andere 
Eigenschaften nachzuweisen. Eine interessante Eigenschaft ware etwa die Beschrankung 
des Ressourcenverbrauchs eines Bytecode-Programms auf ein gewisses MaB. 
5 Der Einsatz des erfindungsgemaBen Verfahrens erlaubt es, das sicherheitskritische Konzept 
der Bytecode-Verifikation auf einer formalen Grundlage zu implementieren. Dadurch 
erreicht man die hochstmogliche Sicherheit ftir diesen Aspekt der Java-Technologie. Man 
kann erwarten, daB sich die Technik daniberhinaus auch zum Nachweis weitergehender 
Eigenschaften von Applets einsetzen lafit, so daB ein grdBerer Einsatzbereich interessant 
10 wird. 

Insbesondere im Umfeld Java-fahiger Smartcards (wobei sich Java-fahig darauf bezieht, 
Bytecode-Programme ausftihren zu kdnnen), wo die Sicherheitsanforderungen extrem hoch 
sind, ist diese Technik interessant. Java-fahige Smartcards erlauben es, Programme zu laden 

15 und auszufuhren, und zwar auch dann, wenn sie sich bereits im Besitz des Endkunden 
befindet (dies ist mit herkommlichen Smartcards nicht oder nur eingeschrankt mdglich). 
Dabei ist es von groBter Wichtigkeit, daB nur solche Programme geladen und ausgefuhrt 
werden, die die Integritat der Karte und der darauf gespeicherten Daten nicht verletzen, 
denn der MiBbrauch solcher Daten kann erheblichen personlichen oder finanziellen Schaden 

20 anrichten. 

Durch die beschriebene Technik kann die Sicherheit von Bytecode-Programmen garantiert 
und durch zusatzhche Erweiterungen eine gewisse Funktionahtat zugesichert werden. Damit 
kann das Vertrauen in Anwendungen erhoht werden, die auf sicherheitskritischen 
Plattformen wie Smartcards ablaufen sollen. 
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Bezugszeichenfiste 

JVM Interpreter fur Java-Bytecode-Programme (Java Virtual Machine) 

M endliches Zustandsubergangssystem 

S Bedingungsmenge 

s Bedingung von S 

V Befehlsverzeichnis fur Bytecode-Instruktionen 

C 1 Bedingungen, die ein Zustand der JVM erfullen mufl 

C2 Bedingungen, die die JVM erfullen muC 

Al Eigenschaft, die fur Bedingungen in V gilt 

B Programminstruktion 

P Parameter fur B 
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Patentanspriiche: 

1 . Verfahren zur Priifung von Java-Bytecode-Programmen auf Sicherheitseigenschaften 
nach dem Prinzip der Bytecode- Verification, 
dadurch gekennzeichnet, daB 

a) die Funktionsweise des zu priifenden Bytecode-Programms unter Verwendung eines 
Algorithmus, der das Verhalten der Bytecode-Instruktionen beschreibt, von einem 
potentiell unendlichen Zustandsubergangssystem auf ein endliches 
Zustandsubergangssystem (M) und der Zustandsraum des Interpreters (JVM) auf eine 
endliche Menge von Zustanden im endlichen Zustandsubergangssystem (M) abgebildet 
werden, wobei alle nicht fiir die Zulassigkeit des zu priifenden Bytecode-Programms 
erforderlichen Informationen entfallen, so daB das daraus resultierende endliche 
Zustandsiibergan-gssystem (M) ausschlieBlich Typinformationen zumNachweis der 
Zulassigkeit des Bytecode-Programms enthalt, welche in einen Modelchecker eingegeben 
werden, daB 

b) die Eigenschaften, die ein zulassiges Bytecode -Programm kennzeichnen, in einer 
Logik in Form von Formeln erfaBt und als Bedingungsmenge (S) in den Modelchecker 
eingegeben werden, wobei der Modelchecker jede einzelne Bedingung (s) der 
Bedingungsmenge (S) als Spezifikationssprache fiir Systemeigenschaften von 
Bytecode-Programmen interpretiert, und daB 

der Modelchecker fur jede Bedingung (s) der Bedingungsmenge (S) priift, ob ob sie vom 
Zustandsubergangssystem (M) erfullt ist, und daB das uberpriifte Bytecode-Programm 
automatisch zur weiteren Verarbehung freigegeben wird, wenn das 
Zustandsubergangssystem (M) alle Bedingungen{s) der Bedingungsmenge (S) erfullt. 



INTERNATIONAL SEARCH REPORT 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 6 G06F11/G0 



According to International Patent Classification (IPC) or to both national classification and IPC 



Intern tal Application No 

PCT/EP 99/04438 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 6 G06F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the International search (name of data base and. where practical search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



£P 0 685 792 A (AT&T CORP.) 
6 December 1995 (1995-12-06) 
abstract 



□ 



Further documents are Osted In the continuation of box C. 



Patent family members are Osted in annex, 



* Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
°E" earlier document but published on or after the international 

filing date 

V document which may throw doubt3 on priority claim(s)or 
which Is cited to establish the publication date of another 
citation or other special reason (as specified) 

TD" document referring to an oral disclosure, use. exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority data claimed 



T later document published after the international filing date 
or priority date and not In conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed Invention 
cannot be considered novel or cannot be considered to 
involve an Inventive step when the document Is taken alone 

•Y" document of particular relevance; the claimed invention 
cannot be considered to involve an Inventive step when the 
document Is combined wflh one or more other such docu- 
ments, such combination being obvious to a person skilled 
In the art. 

"A* document member of the same patent famfly 



Date of the actual completion of the international search 



20 October 1999 



Date of mailing of the International search report 



28/10/1999 



Name and mafog address of the ISA 

European Patent Office. P.a 5618 PatenOaan 2 
KL - 22B0 HV RQswijk 
TeL (+31-70) 340-2040, Tx. 31 651 epo nj. 
Fax: (+31-70) 340-3016 



Authorized officer 



Corremans, G 



Foot PCTrtSA/210 (Mcond shoot) (Jury 1992) 



INTERNATIONAL SEARCH REPORT 

information on patent family members 



nal Application No 

PCT/EP 99/04438 



Patent document 
cited In search report 



Publication 
date 



Patent family 
members) 



Publication 
date 



EP 685792 



06-12-1995 



CA 
JP 
US 



2147536 A 
7334566 A 
5615137 A 



02-12-1995 
22-12-1995 
25-03-1997 



Fwm PCTflSA/210 <jxan tat#y anno] (JiJy 1892) 



INTERNATIONALER RECHERCHENBERICHT 



Intern laies Aktenzelchen 

PCT/EP 99/04438 



A. KLASSFIZIERUNG DES ANMELDUNGSGEGENSTANDES 

IPK 6 G06F11/00 



Nach der Intemationalen Patent Massif flcatton (IPK) oder nach der nationalen Klasstfikatlon und der IPK 



B. RECHERCHIERTE GEBIETE 



Recherchterter Mlndeatprufstoff (Klasatfikattonssystem und KlasstfikationssymboJe ) 

IPK 6 G06F 



Recherchierte aber nlcht rum Mindestprufatoff gehdrende Verofferrtltehungen, soweit diese unter did recherchierten Gebleta faQan 



Wahrend der intematlonaien Recherche konsuttterte elektronische Dalenbank (Name der Datenbank und evtt verwendete Suchbegriffe) 



C. ALS WESENTLICH ANGESEHENE UNTERLAGEN 



KategonV Bezelchnung der Verdffentllchung, so we It erforderflch unter Angabe der In Betracht kommenden Telle 



Betr. Anspruch Nr. 



EP 0 685 792 A (AT&T CORP.) 
6. Oezember 1995 (1995-12-06) 
Zusammenfassung 



□ 



Wettere VeroffentOchungen slnd der Fortsetzung von Feid C zu 



Stone Anhang PatentfamQIe 



* Besondare Kategorien von angegebenen Verottentfichungen 

"A* Verftffentllchung, die den aiigemelnen Stand der Technik defirtiert 
aber nicht ais besonders bedeutsam anzusahen 1st 

"E' fiHeres Dokument das jedoch erst am Oder nach dem InternationaJen 
Anmektedatum verdffentOcht worden is4 

V Ver&ffentltehung, die geekjnet 1st einen Prlorttaisanspruch zwelfelhaft er- 
ache hen zu lassen, oder durch die das Veroffentllchungsdatum elner 
anderen tm Recherchenbericht gananrttsn VardffenUfchung beiegt werden 
son oder die a us einem anderen besonderen Grund angegeben tst (wie 
au sg ef Oh rt) 

"O" VeroffentOchung, die eteh auf elne mundflche Offenbarung, 

sine Benutzung, etna Ausstettung oder andere MaBnahmen bezieht 

"P" VeroffenUichung, (fie vor dem WemaflonaJen Anmeldedatum, aber nach 
dem beanspruchten Prloritalsdatum veroff entOcht worden 1st 



T Spatere VeroffentHcnung, die nach dem Intemationalen Anmetdedatum 
oder dem PriorttStsdatum veroffantBcht worden 1st und mit der 
AnmeUung nicht koBkflert sondem nur zum Verstandnis das der 
Erfindung zugnrndaiiegenden Prinzips oder der ihr zugrundeliegenden 
Theorte angegeben tef 

"X" VeioffentDchung von besonderer Bedeutung: die beanspruchte Erfindung 
kann afleln auf grund closer VeroffenUichung nicht a Is neu Oder auf 
erftndertscher Tatigket beruhend betrachtet werden 

*Y' Verdffentllchung von besonderer Bedeutung: (fie beanspruchte Erfindung 
kann nicht ais auf erfindenacher T&tigkeft beruhend betrachtet 
warden, wenn die Veroflentichung mit einer oder mehreren anderen 
Veroffentfichungsn closer Kategorte in Vetblndung gebracht wW und 
dtese VerWndung fur einen Fachmann rtaheBegend 1st 
Veroffentlichung, de MitgBed derseben Patentfamflie 1st 



Datum des Abschlusaas der intemationalen Recherche 



20. Oktober 1999 



Abaandedatum das tntamationalen Recherchenberichts 



28/10/1999 



Name und Postanschrtft der Intemationalen Recharchenbahorde 
EuropaJsches Patentamt, P.a 5818 Patanttean 2 
NL - 2280 HV RJJaw^k 
TeL (+31-70) 340-2040, Til 31 651 epo nl. 
Fax: (+31-70) 340-3016 



BevoUmAcrrtJgter BecQensteter 



Corremans, G 



Fomttafl PCT4SA/210 (BUfl 2) (Jul 1992) 



INTERN A.TIONALER RECHERCHENBERICHT 

Angaben zu VerOflentflchungen, die zur eelben PatentfamHIe gehdren 



lm Recherchanbericht 
angeftihrtes Patentdokument 



Datum der 
Verftffentiichung 



Intern ales Aktonzelchen 

PCT/EP 99/04438 



Mitgfied(er) der 
Patentfamilie 



Datum der 
Ver6ffen«ichung 



EP 685792 



06-12-1995 



CA 
JP 
US 



2147536 A 
7334566 A 
5615137 A 



02-12-1995 
22-12-1995 
25-03-1997 



FomMffl PCT/lSA/210 (Artrano PalontomOoH-h* 1892) 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUJ.OFF AT TOP, BOTTOM OR SIDES 

□ F>0ED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAYSCALE DOCUMENTS 



□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




INES OR MARKS ON ORIGINAL DOCUMENT 



